Kapitel 27 Fertigstellen eines Projekts

Bis zum Kapitel 26 behandelte dieses Buch Themen, die in direktem Zusammenhang mit der Programmierung einer Anwendung zu betrachten sind: angefangen bei der objektorientierten Programmierung über diverse Klassen und Techniken bis hin zu den Windows-Anwendungen. Um diese grundlegenden Voraussetzungen herum siedeln sich aber auch noch andere Aspekte an, die eine Anwendung erst richtig abrunden, denen Beachtung geschenkt werden muss, um den gesteigerten Erwartungen und vielleicht auch Anforderungen zu genügen.

Dazu gehört fast zwangsläufig eine benutzerfreundliche Installationsroutine, obwohl eine .NET-Anwendung auch durch einfaches Kopieren der EXE-Datei »installiert« werden kann. Zudem bietet Visual Studio 2005 mit ClickOnce eine neue Verteilungsstrategie an, der mit Sicherheit aufgrund ihres einfachen Verteilungs- und Update-Mechanismus die Zukunft gehört.

Soll die Anwendung in mehrere Sprachräume ausgeliefert werden, sollte auch eine entsprechende Sprachversion ausgeliefert werden. Ich muss zugeben, sich erst am Ende eines Projekts darüber Gedanken zu machen, wäre der denkbar schlechteste Zeitpunkt. Diese Entscheidung muss vor dem Start der Applikation gefällt werden. Aber da ich Ihnen nicht den chronologischen Ablauf eines .NET-Projekts in diesem Buch zeigen wollte, sondern Sie eher in einer vernünftigen Reihenfolge in das Entwickeln von Desktop-Anwendungen einführen wollte, steht dieses Thema erst im letzten Kapitel.

Über diese beiden Themen hinaus muss ich Ihnen auch noch etwas zu den Konfigurationsdateien erzählen, die ich in Kapitel 14 schon erwähnt habe und eine der wesentlichen Charakteristika einer .NET-Anwendung sind. Und damit möchte ich auch das letzte Kapitel in diesem Buch eröffnen.

27.1 Konfigurationsdateien 

27.1.1 Einführung 

Ohne Neukompilierung einer Anwendung können Konfigurationsdateien das Laufzeitverhalten einer Anwendung beeinflussen. In einer Konfigurationsdatei werden Vorgaben getroffen, die beim Starten einer Anwendung von der Common Language Runtime (CLR) ausgewertet werden. Darüber hinaus ist auch während der Laufzeit der Zugriff auf eine Konfigurationsdatei mittels Programmcode möglich.

Doch was beschreiben Konfigurationsdateien? Letztendlich handelt es sich dabei nur um Daten, die von einer Anwendung während der Ausführung benötigt werden. Dabei kann es sich um Daten handeln, die sicherstellen, dass der Zustand einer Anwendung bei einem Neustart genauso restauriert wird, wie es beim Schließen der Anwendung der Fall war. Es kann sich um Variableninhalte handeln, Verbindungszeichenfolgen für ADO.NET oder auch die Angabe darüber, welche Version einer bestimmten Assembly aus dem Global Assembly Cache (GAC) geladen werden soll.

In der Vor-.NET-Zeit diente die Registry des Windows-Betriebssystems als globaler Datenspeicher der Anwendungen und des Rechners, Anwendungsdaten wurden oft in INI-Dateien beschrieben. Mit den .NET-Konfigurationsdateien ist praktisch das Ende des proprietären Datenspeichers Registry eingeläutet worden, INI-Dateien sind zur Bedeutungslosigkeit degradiert. Sicher wird es noch viele Jahre dauern, bis auf beide Elemente vollständig verzichtet werden kann, denn zu viele Anwendungen sind elementar davon abhängig. Aber der weitere Weg ist bereits vorgezeichnet.

Konfigurationsdateien wurden auch vom .NET Framework 1.0/1.1 unterstützt. Mit der Version 2.0 werden die Möglichkeiten jedoch deutlich erweitert. Nicht nur, dass sich die Anzahl der verfügbaren Klassen im entsprechenden Namespace System.Configuration vervielfacht hat, auch die Beschreibung des Inhalts einer Konfigurationsdatei weicht von dem der Version 1.0/1.1 ab, ohne jedoch den Verlust der Abwärtskompatibilität beklagen zu müssen.

Es gibt mehrere verschiedene Konfigurationsdateien, die unter .NET eine mehr oder weniger entscheidende Rolle einnehmen. Wir haben uns im Rahmen dieses Buches mit Anwendungen auf der lokalen Maschine beschäftigt, deshalb können wir eine Aufzählung auch auf drei Typen beschränken:

Anwendungskonfigurationsdateien

Herausgeberrichtliniendateien

Maschinenkonfigurationsdatei (machine.config)

In erster Linie werden wir uns in diesem Abschnitt mit den Anwendungskonfigurationsdateien beschäftigen. Dieser Typus verzeichnet gleichzeitig auch die offensichtlichste Änderung unter .NET 2.0, denn er splittet sich in zwei Dateien auf, die unterschiedliche Daten beschreiben:

Anwendungsdaten, die für die gesamte Anwendung gültig und unabhängig vom jeweiligen Benutzer sind

Daten, die benutzerspezifisch sind

Das alles werden wir im weiteren Verlauf dieses Kapitels noch genauer untersuchen.

Konfigurationsdateien sind XML-Dateien. XML (Extended Markup Language) ist ein nach strengen Richtlinien definierter Standard. Dieser ähnelt im ersten Moment HTML, erlaubt aber nicht dieselben Freizügigkeiten. Um nur ein Beispiel zu nennen: Während HTML der Groß-/Kleinschreibung keine Beachtung schenkt, spielt das bei XML eine entscheidende Rolle. An dieser Stelle die Syntax von XML zu beschreiben, würde deutlich zu weit führen. Dafür gibt es ausreichend Literatur, auf die Sie im Bedarfsfall zurückgreifen können. Andererseits ist es auch nicht notwendig, sich im Rahmen der Konfigurationsdateien eingehend mit der Thematik XML auseinander zu setzen, denn XML-Dateien sind ASCII-Dateien, deren Inhalt auch ohne große Hintergrundkenntnisse interpretiert und gegebenenfalls geändert oder angepasst werden kann.

27.1.2 Die verschiedenen Konfigurationsdateien 

Bevor wir uns exemplarisch eine Konfigurationsdatei ansehen, sollten wir uns darüber bewusst sein, dass es unter .NET mehrere verschiedene Konfigurationsdateien gibt, die durchaus auch gleiche Elemente aufweisen können. Typisch für alle Konfigurationsdateien ist die Dateierweiterung .config. Verschaffen wir uns zuerst einen allgemeinen Überblick.

Anwendungskonfigurationsdatei: Falls einer .NET-Anwendung eine Anwendungskonfigurationsdatei zugeordnet wird, ist diese immer im Stammverzeichnis der Anwendung zu finden. Der Name einer Konfigurationsdatei setzt sich aus dem Namen der Programmdatei und dem Suffix .connfig zusammen. Lautet die Programmdatei MyApplication.exe, heißt die Konfigurationsdatei demnach MyApplication.exe.config.

Eine Konfigurationsdatei, die dieser Namenskonvention folgt, muss im Stammverzeichnis der Anwendung gespeichert werden und wird vor dem Start der Anwendung von der CLR ausgewertet. Die Einstellungen in der Anwendungskonfigurationsdatei sind daher spezifisch für die Anwendung und haben keine Auswirkungen auf andere Anwendungen.

Obwohl wir uns in diesem Buch nicht mit Webanwendungen beschäftigen, sei an dieser Stelle erwähnt, dass einem Webprojekt (ASP.NET-Webdienst, ASP.NET-Webanwendung) immer eine Anwendungskonfigurationsdatei zugeordnet wird, die Web.config heißt.

Publisher-Richtliniendatei (Herausgeberrichtliniendatei): Dieser Konfigurationsdateityp kann zusammen mit dem Update oder Service-Pack einer globalen Assembly ausgeliefert werden. Eine Publisher-Richtliniendatei, in der .NET-Dokumentation auch als Herausgeberrichtliniendatei bezeichnet, hat die Aufgabe, den Zugriff der Anwendungen, die normalerweise die Dienste der »alten« Assembly in Anspruch nehmen würden, auf eine neue Version umzuleiten. Damit hat zumindest der Hersteller der Komponente das seinige dazugetan, um zu vermeiden, dass die Anwendungen weiterhin eine möglicherweise fehlerhafte Version benutzen.

Computerkonfigurationsdatei: Der Name dieser Konfigurationsdatei lautet machine.config. Haben Sie bei der Installation keine anderen Vorgaben getroffen, befindet sich diese Datei im Ordner:

\Windows\Microsoft .NET\Framework\v<Versionsnummer>\Config

In der Computerkonfigurationsdatei sind alle .NET betreffenden Einstellungen des lokalen Rechners zentral beschrieben. Daher ist diese Konfigurationsdatei auch sehr groß und erscheint mit ihren zahllosen Einträgen, die sich auf das gesamte Laufzeitverhalten von .NET-Anwendungen und -Komponenten auswirken, unüberschaubar.

Installieren Sie die neue Version einer Komponente, die von allen Anwendungen der lokalen Maschine gemeinsam benutzt werden soll, kann die neue Komponentenversion in den einzelnen Anwendungskonfigurationsdateien beschrieben werden oder alternativ in machine.config.

Die Aufrufreihenfolge der Konfigurationsdateien

Mit den Konfigurationsdateien stehen insgesamt drei Möglichkeiten zur Verfügung, Einstellungen auszuwerten oder den Aufruf einer bestimmten Assembly-Version zu steuern. Die Suche nach den Konfigurationsdateien erfolgt dabei in der folgenden Reihenfolge:

Nehmen wir an, eine Anwendung hätte die globale Assembly MyAssembly eingebunden, deren Version 1.0.0.0 sei. MyAssembly ist im Manifest der Anwendung aufgeführt, einschließlich des öffentlichen Schlüssels und der Versionsnummer. Nehmen wir weiter an, dass auf demselben Computer bereits die neueren Versionen 1.0.1.0 und 1.0.2.0 von MyAssembly installiert sind. Nach der Installation befinden sich somit insgesamt drei verschiedene Versionen der globalen Assembly im GAC.

Wird die Anwendung gestartet, ist zunächst das Manifest ausschlaggebend dafür, welche Version der Assembly geladen werden soll. Die Laufzeitumgebung merkt sich die Version und sucht anschließend nach einer Anwendungskonfigurationsdatei. Ist eine solche im Anwendungsverzeichnis gespeichert und enthält sie einen Eintrag, der die Umleitung zu einer anderen Version beschreibt, überschreibt der Eintrag in der Anwendungskonfigurationsdatei den Eintrag im Manifest.

Nach der Suche und der Auswertung der Anwendungskonfigurationsdatei interessiert sich die Laufzeit für eine möglicherweise existierende Publisher-Richtliniendatei von MyAssembly. Hat der Entwickler der Assembly eine solche bereitgestellt und ist sie im GAC installiert, überschreibt deren Versionsangabe diejenige, die bis zu diesem Zeitpunkt gültig war.

Im letzten Schritt durchforstet die Laufzeit die Computerkonfigurationsdatei, die im Gegensatz zu den beiden vorher aufgeführten nicht optional ist. Hat der Anwender in machine.config eine Versionsumleitung eingetragen (dazu sind administrative Rechte notwendig), gilt diese vor allen anderen.

Hier klicken, um das Bild zu Vergrößern

Abbildung 27.1     Die Aufrufreihenfolge der Konfigurationsdateien

Entscheidend dafür, auf welche Assembly-Version die Anwendung zugreift, ist der zuletzt gefundene Eintrag. Sollen alle Anwendungen grundsätzlich mit einer bestimmten Version arbeiten, genügt ein Eintrag in die Computerkonfigurationsdatei, falls der Hersteller der Komponente nicht selbst für eine Publisher-Richtliniendatei gesorgt hat. Auf eine Anwendungskonfigurationsdatei kann in diesem Fall verzichtet werden – es sei denn, andere Vorgaben oder Einstellungen müssen getroffen werden, die nichts mit dem Versionsaufruf zu tun haben.

Es könnte auch passieren, dass in der Computerkonfigurationsdatei die Umleitung auf eine Version von MyAssembly angegeben ist, die sich aber als nicht abwärtskompatibel für eine ganz bestimmte Anwendung erweist, während andere Anwendungen problemlos damit zusammenarbeiten können. Dann besteht die Möglichkeit, in der Anwendungskonfigurationsdatei der betroffenen Anwendung den Automatismus der Versionsumleitung abzuschalten.

27.1.3 Die Struktur einer Anwendungskonfigurationsdatei 

Da eine Anwendungskonfigurationsdatei optional ist, muss Sie einem Programm ausdrücklich hinzugefügt werden. Sie können dazu das Visual Studio 2005 benutzen, Sie können aber auch die Anwendungsdatei einer .NET-Anwendung nach deren Installation bereitstellen. Im einfachsten Fall schreiben Sie den gewünschten XML-Code mit dem MS Editor oder einem anderen beliebigen ASCII-Editor. Anschließend speichern Sie die Text-, also XML-Datei mit dem vorgeschriebenen Bezeichner im Anwendungsverzeichnis. Das ist schon alles.

Wir wollen nun zum ersten Mal eine Konfigurationsdatei einem Projekt mit Visual Studio 2005 hinzufügen. Markieren Sie dazu im Projektmappen-Explorer das Projekt, öffnen dessen Kontextmenü und wählen Hinzufügen... N Neues Element hinzufügen. Im nächsten Schritt markieren Sie im Dialogfenster den Typ Anwendungskonfigurationsdatei und bestätigen die Auswahl.

Die Projektdateien werden danach um die Datei App.config ergänzt. Den Namen App.config dürfen Sie nicht ändern, weil der Compiler nur eine Datei mit diesem Namen als spätere Anwendungskonfigurationsdatei interpretiert. Bei der Kompilierung des Projekts wird aus App.config automatisch der Dateiname generiert, welcher der Namenskonvention entspricht.

Im Arbeitsbereich der Entwicklungsumgebung wird ein neues Fenster mit dem Inhalt der Datei App.config angezeigt. Sie enthält bereits den elementarsten XML-Code nebst Einträgen zur Protokollierung mit Listenern:

Mit der ersten Zeile, die als XML-Deklaration oder auch als Prolog bezeichnet wird, wird der Einstiegspunkt in das XML-Dokument festgelegt. Neben der Versionsnummer wird auch der zum Lesen des Dokuments verwendete Zeichensatz, hier UTF-8, beschrieben.

Jedes XML-Dokument hat ein so genanntes Stammelement. Bei den Konfigurationsdateien ist es das <configuration>-Element. Alle Informationen, die zwischen dem einleitenden und dem ausleitenden Tag stehen und ihrerseits selbst Elemente sind, werden dazu benutzt, die Anwendung zu konfigurieren.

Ich möchte Ihnen nun eine Konfigurationsdatei zeigen, die nicht nur den erforderlichen Strukturrahmen aufweist, sondern gleichzeitig auch bereits Informationen in sich birgt.

Dieser Anwendungskonfigurationsdatei liegt eine Windows-Anwendung mit dem Bezeichner WinApp zugrunde. Der besseren Übersicht wegen sind einige unwesentliche Passagen nur gekürzt wiedergegeben.

Innerhalb von <configuration> sind drei Sektionen definiert:

<configSections>

<userSettings>

<applicationSettings>

<configSections> gibt die diesem Element folgenden Konfigurationsabschnitte an und ist immer das direkt <configuration> untergeordnete Element.

Die Notationen in den beiden Abschnitten <applicationSettings> und <userSettings> sind identisch. Zunächst wird ein neuer untergeordneter Abschnitt eröffnet, der eine Klasse angibt, hier z.  B.:

Die Klasse heißt MySettings, der Namespace ist WindowsApplication1.My. Namespace und Klasse werden von Visual Studio automatisch erzeugt. MySettings definiert hauptsächlich Eigenschaftsmethoden, um den Zugriff auf die in der Konfigurationsdatei abgelegten Daten zu ermöglichen.

Die untergeordneten <setting>-Elemente beschreiben mit dem Attribut name den Bezeichner der gespeicherten Variablen, serializeAs gibt den Datentyp an. Meist werden die Daten als Zeichenfolge serialisiert, ansonsten sind auch noch xml, binary und custom mögliche Alternativen. Das Tag <value> schließlich beschreibt den gespeicherten Wert.

Die Abschnitte <userSettings> und <applicationSettings>

Benutzerunabhängige Daten sind in der Sektion <applicationSettings> festgelegt. Alle Informationen, die dieser Abschnitt beschreibt, gelten uneingeschränkt für jeden Benutzer der Anwendung. Im Beispiel oben wird nur eine Dateninformation in diesem Abschnitt festgelegt, welche die Bezeichnung Variable2 hat und die Zeichenfolge 25 beschreibt. Es könnte sich dabei allerdings auch um einen beliebigen anderen Datentyp handeln.

Variable2 kann beim Starten der Anwendung ausgewertet und von der laufenden Anwendung weiterverarbeitet werden. Solange sich nichts am Inhalt von Variable2 ändert, käme das der Deklaration einer gleichnamigen Variablen im Code gleich. Sollte jedoch ein abweichender Wert wünschenswert sein, kann dieser in der Konfigurationsdatei geändert werden, ohne dass eine Neukompilierung erforderlich ist. Ein besonderes Charakteristikum von <applicationSettings> ist, dass sich die Werte nicht mittels Code aus einer laufenden Anwendung heraus editieren lassen. Änderungen sind nur über einen entsprechenden Editor möglich. Weiter unten in diesem Kapitel werde ich Ihnen aber mit dem ähnlich lautenden Abschnitt <appSettings> eine Möglichkeit zeigen, dennoch anwendungsspezifische Daten in einer Konfigurationsdatei mittels Code zu manipulieren.

<applicationSettings> ist denkbar ungeeignet, benutzerspezifische Einstellungen zu speichern. Abgesehen von der schnell wachsenden Größe der Konfigurationsdatei bei steigender Benutzeranzahl würde der Inhalt auch jedem anderen Benutzer offengelegt wie ein Buch. Deshalb werden benutzereigene Einstellungen in der Sektion <userSettings> der Anwendungskonfigurationsdatei beschrieben. Daten, die hier eingetragen sind, gelten als Standardwerte für den jeweiligen Anwender. Kommt es zu einer Änderung der Daten, werden diese in einer Datei mit dem Namen user.config im jeweiligen Windows-Benutzerprofil unter

Dokumente und Einstellungen\<Benutzer>\Lokale Einstellungen\Anwendungsdaten\ <Firma>\<Anwendung>

gespeichert. Daraus können Sie auch schlussfolgern, dass im Gegensatz zu <applicationSettings> die Daten, die im Abschnitt <userSettings> definiert sind, mittels Code verändert werden können.

27.1.4 Konfigurationsdateien mit Visual Studio 2005 bereitstellen 

Eine Konfigurationsdatei wie die oben beschriebene müssen Sie natürlich nicht mit dem MS Editor oder ähnlichen Programmen mühevoll selbst schreiben. Greifen Sie besser auf die Fähigkeiten von Visual Studio 2005 zurück.

Öffnen Sie dazu den Knoten My Project im Projektmappen-Explorer und klicken auf Settings.settings doppelt. In dem sich daraufhin öffnenden Fenster können Sie auf einfachste Weise die Einträge der Abschnitte <userSettings> und <applicationSettings> vornehmen. In der Spalte Name tragen Sie den Namen der Variablen ein, und unter Typ legen Sie den Datentyp fest. Ob es sich um eine allgemeine oder um eine benutzerspezifische Variable handelt, wählen Sie aus der der Spalte Bereich zugeordneten Liste aus. In der letzten Spalte können Sie auch den Startwert der Variablen bestimmen. Eine Vorgabe ist hier nicht notwendig.

Hier klicken, um das Bild zu Vergrößern

Abbildung 27.2     Festlegen der Konfigurationseinstellungen im Visual Studio 2005

Weitere Sektionen

Die Sektionen in einer Anwendungskonfigurationsdatei beschränken sich nicht nur auf die zuvor aufgeführten <configSettings>, <applicationSettings> und <userSettings>. Darüber hinaus stehen Ihnen weitere Abschnitte zur Verfügung, um die Sie die Konfigurationsdatei ebenfalls optional erweitern können. Darüber hinaus können Sie auch eigene Sektionen definieren.

Zwei vordefinierte Sektionen seien an dieser Stelle genannt:

<connectionStrings>

<appSettings>

<connectionStrings> ist ein Konfigurationselement, das die Ablage mehrerer Verbindungszeichenfolgen für ADO.NET erlaubt. Damit ist es möglich, zur Laufzeit einer Anwendung unter Umständen sogar aus einer längeren Auswahlliste den gewünschten Produktionsdatenbankserver auszuwählen.

<appSettings> gab es bereits unter .NET Framework 1.0/1.1. Es erfüllt die gleiche Aufgabe wie die Sektion <applicationSettings>, ist aber dazu befähigt, aus dem Code der laufenden Anwendung heraus editierbar zu sein.

Die Möglichkeiten, Einfluss auf eine .NET-Anwendung über eine Konfigurationsdatei auszu-üben, sind jedoch noch weitaus größer. Sie können beispielsweise einen Abschnitt <startup> festlegen, der die von der Anwendung unterstützte Version der CLR beschreibt. Den optionalen Abschnitt <runtime> lernen Sie weiter unten noch kennen. Er enthält Informationen über Assembly-Bindungen.

Die Eigenschaftsbindung von WinForm-Komponenten

In vielen WinForm-Anwendungen werden Sie Daten insbesondere für den angemeldeten User speichern wollen. Beispielsweise möchten Sie gewährleisten, dass die Position und Größe eines Fensters bei einem Neustart der Anwendung so wiederhergestellt werden, wie sie beim Schließen der Anwendung waren. Vielleicht sollen auch noch weitere Zustände vollständig restauriert werden, beispielsweise der Inhalt diverser Textboxen.

Natürlich können Sie jede in der Konfigurationsdatei zu speichernde Einstellung im Dialog Settings.settings eintragen (siehe Abbildung 27.2). Im Eigenschaftsfenster der GUI-Komponenten wird Ihnen jedoch mit ApplicationSettings eine einfachere und intuitivere Alternative angeboten. In einem Dialog können Sie zuerst die Eigenschaft auswählen, deren Einstellung Sie in der Konfigurationsdatei speichern wollen. Bei der Wahl wird Ihnen ein zweiter Dialog angeboten, in dem Sie einen Standardwert eintragen können und den Bezeichner der Einstellung festlegen. Sie müssen sich auch entscheiden, ob die Einstellung benutzerspezifisch (User) ist oder auf Anwendungsebene gilt (Application).

Hier klicken, um das Bild zu Vergrößern

Abbildung 27.3     Festlegen einer Eigenschaftseinstellung für die Speicherung in der Konfigurationsdatei

Mit den in Abbildung 27.3 gezeigten Einstellungen wird die App.config-Datei um den folgenden Eintrag im Abschnitt <userSettings> ergänzt.

Das Element value weist hier keinen Eintrag auf, weil unter DefaultValue keine Angabe gemacht worden ist. Ein Eintrag wäre als Standardwert für jeden Benutzer so lange gültig, bis der Benutzer einen individuellen Wert speichert. Wie Sie wissen, werden alle vom Standard abweichenden Einträge im Abschnitt <userSettings> in user.config abgelegt.

27.1.5 Einträge der Anwendungskonfigurationsdatei auswerten 

Im folgenden Beispiel enthält eine WinForm drei Textboxen, in denen der Benutzer seine Adressdaten eintragen kann. Um die vorgenommenen Einträge zu speichern, muss er das Häkchen in der Checkbox setzen. Die Daten sollen dann natürlich in der benutzereigenen user.config-Datei gespeichert werden. In jeder der Textboxen wird, solange keine benutzerspezifischen Daten vorliegen, ein Standardtext angezeigt. Darüber hinaus wird auch die aktuelle Position des Fensters während des Schließvorgangs gespeichert.

Die Beschriftung der Titelleiste der Form soll einem Eintrag in der Konfigurationsdatei entnommen werden, der anwendungsbezogen ist. Im ersten Moment ist das natürlich kein großer Vorteil, aber es wird damit die Option offengehalten, durch Änderung des Eintrags in der Konfigurationsdatei allen Benutzern eine von der Vorgabe abweichende Titelleistenbeschriftung anzuzeigen, ohne den Code neu kompilieren zu müssen. Wie Sie wissen, muss die Anwendungskonfigurationsdatei dazu nur mit einem passenden Editor geöffnet werden.

Hier klicken, um das Bild zu Vergrößern

Abbildung 27.4     Ausgabe des Beispiels »UserSettingsDemo«

Die in der Entwicklungsumgebung resultierende Datei app.config sehen wir uns nun an. Aus Gründen der Übersichtlichkeit ist auch hier wiederum der Abschnitt <configSections> stark gekürzt. Sie können sich aber bei Interesse die vollständigen Einträge im Beispielcode der Anwendung UserSettingsDemo auf der Buch-CD ansehen.

Die Speicherung der Textboxeinträge in user.config erfolgt, wenn der Anwender das Fenster schließt. Hier bietet sich das Ereignis FormClosing der Form an. Für das Speichern ist nach vorheriger Prüfung der Checkbox nur eine Anweisungszeile notwendig. Das Laden der gespeicherten Daten erfolgt automatisch, ohne dass Sie dafür auch nur eine Codezeile schreiben müssen.

Wenn es Sie interessiert, auf welcher Grundlage diese Anweisung basiert, öffnen Sie die Datei Settings.Designer.vb, die Sie innerhalb des Knotens My Project im Projektmappen-Explorer finden. Diese Datei wird von Visual Studio 2005 generiert. Für sie gilt dasselbe wie auch für die Methode InitializeComponent einer WinForm: Ändern Sie sie nicht, um nicht unliebsame Überraschungen zu erleben.

Settings.Designer.vb enthält die Beschreibung der Klasse MySettings, die von ApplicationSettingsBase abgeleitet ist. Diese Klasse ist ein Wrapper um die Konfigurationsdatei und somit das Bindeglied zwischen den Konfigurationseinstellungen und dem Programmcode. In der Klasse werden alle Einstellungen aus der Anwendungskonfigurationsdatei als Eigenschaftsmethoden veröffentlicht. Die benutzerspezifischen haben einen get- und set-Zweig, die anwendungsspezifischen implementieren nur get und liefern deshalb lediglich den Wert zurück.

Die Ereignisse eines »MySettings«-Objekts

Das Objekt MySettings kann vier Ereignisse auslösen, die Sie behandeln können:

Das SettingsSaving-Ereignis wird von der Save-Methode ausgelöst, bevor die Anwendungseinstellung gespeichert wird. Der zugeordnete Ereignishandler vom Typ CancelEventArgs kann den eingeleiteten Speichervorgang abbrechen.

Das SettingChanging-Ereignis tritt ein, bevor eine Anwendungseinstellung über den Indexer geändert wird. Der zweite Parameter des Ereignishandlers ermöglicht das Abrufen der zu ändernden Einstellung sowie des zugewiesenen Werts als auch darüber hinaus den Abbruch der Operation.

PropertyChanged und SettingsLoaded werden ausgelöst, wenn sich eine Eigenschaft ändert bzw. Einstellungen geladen werden.

27.1.6 Die Klassen »Configuration« und »ConfigurationManager« 

Während sich im Namespace System.Configuration des .NET Frameworks 1.0/1.1 nur neun Klassen tummelten, hat sich die Anzahl in der Version 2.0 auf deutlich über 100 erhöht. Auch wenn Ihnen auch weiterhin die »alten« Klassen zur Verfügung stehen, empfiehlt die .NET-Dokumentation, auf die neuen zurückzugreifen. Hier nimmt die Klasse Configuration eine entscheidende Position ein. Configuration repräsentiert die Einstellungen einer Anwendung oder des Computers. Die Implementierung der Klasse berücksichtigt dabei, dass Anwendungen die Einstellungen in machine.config erben.

Configuration ist konstruktorlos. Das erinnert uns an die Klasse Graphics, deren Instanzen über andere Wege bereitgestellt werden. Ähnlich ist der Sachverhalt mit Configuration. Hier stellt uns die Klasse ConfigurationManager das entsprechende Configuration-Objekt zur Verfügung.

Configuration gibt uns mit seinen Eigenschaften und Methoden alle Mittel in die Hand, um Sektionen bzw. Sektionsgruppen, den physikalischen Pfad der Konfigurationsdatei abzurufen und Einstellungen zu speichern. In den beiden folgenden Tabellen sind die wichtigsten Eigenschaften und Methoden aufgeführt.

Soweit die Eigenschaften und Methoden von Configuartion. Kommen wir nun zu den Membern von ConfigurationManager.

Die beiden einzigen Eigenschaften, die ConfigurationManager veröffentlicht, lauten AppSettings und ConnectionStrings, über die der Zugriff auf die Abschnitte <appSettings>- und <connectionStrings> möglich wird.

Zudem beschafft diese Klasse mit der Methode OpenExeConfiguration die Referenz auf ein Configuration-Objekt. Das ist deshalb besonders wichtig, weil ConfigurationManager selbst keine Methoden zum Speichern hat. Mit OpenMachineConfiguration ist der Zugriff auf die Datei machine.config sichergestellt.

Wie Sie die Klassen Configuration und ConfigurationManager einsetzen können, zeige ich Ihnen in den beiden folgenden Abschnitten.

27.1.7 Editierbare, anwendungsbezogene Einträge mit <appSettings> 

Einträge, die Sie in der Anwendungskonfigurationsdatei im Abschnitt <applicationSettings> vornehmen, sind nicht editierbar – zumindest aus dem Code einer Anwendung heraus. Man kann die Werte jedoch jederzeit ändern, indem man die Datei mit einem beliebigen Editor öffnet. Das ist insofern sinnvoll, dass nicht ein Benutzer von den Änderungen eines anderen Benutzers abhängig gemacht wird.

Nichtsdestotrotz könnten Sie als Entwickler auch einmal in die Situation kommen, aus dem Code heraus eine anwendungsweite Einstellung ändern zu wollen oder eine neue hinzuzufügen. Über die Hürde, die <applicationSettings> setzt, hilft die Festlegung eines anderen Abschnitts hinweg: <appSettings>. Das nun folgende Beispiel AppSettingsDemo zeigt, wie Sie mit den Klassen Configuration und ConfigurationManager die Einstellungen in <appSettings> beeinflussen können.

Wenn Sie die Anwendung testen wollen, sollten Sie sie nicht aus der Entwicklungsumgebung heraus starten, sondern das Kompilat. Ansonsten werden Sie den Effekt durch permanentes Neuschreiben der Datei app.config nicht sehen können. Die Ausgabe der Anwendung zeigt die folgende Abbildung.

Hier klicken, um das Bild zu Vergrößern

Abbildung 27.5     Die Ausgabe des Beispiels »AppSettingsDemo«

Bei jedem Neustart wird ein zusätzlicher Eintrag in die Anwendungskonfigurationsdatei geschrieben. Es handelt sich hierbei um die aktuelle Uhrzeit. Allerdings sollen nur die beiden letzten Starts auf diese Weise protokolliert werden, alle anderen Einträge werden mit »veraltet« überschrieben.

Für die Ausgabe des aktuellen Inhalts sorgt die Methode ShowAppSettings, in der zuerst alle namentlichen Einträge mit

abgefragt werden. ConfigurationManager.AppSettings liefert uns die Referenz auf ein Objekt vom Typ NameValueCollection. In diesem sind alle Elemente mit einem eindeutigen Schlüssel, einer Zeichenfolge, eingetragen. Alle Schlüssel werden als Array von der Eigenschaft AllKeys bereitgestellt. In einer Schleife werden alle Schlüssel abgegriffen und die zugeordneten Werte an der Konsole ausgegeben.

Als Collection stellt eine NameValueCollection passende Methoden bereit, um die Einträge zu manipulieren. Wir benutzen die Methode Add, um einen Neueintrag hinzuzufügen, und übergeben als Argumente den zuvor gebildeten neuen Elementnamen und anschließend die aktuelle Uhrzeit.

Da wir beabsichtigen, den Neueintrag auch zu speichern, benötigen wir ein Configuration-Objekt. Mit

holen wir uns die Referenz auf das benötigte Objekt, das die Anwendungskonfigurationsdatei verkörpert. Für das Speichern steht uns in Save die passende überladene Methode zur Verfügung.

config.Save(ConfigurationSaveMode.Modified)

Wir müssen nur sagen, welche Elemente wir zu speichern gedenken. Dazu erwartet die von uns bevorzugte Überladung die entsprechende Angabe. Die Enumeration Configuration-SaveMode beschreibt mit Full, Minimal und Modified alle denkbaren Fälle.

27.1.8 Auswertung der Verbindungszeichenfolgen 

Eine weitere, sehr sinnvolle Neuerung im .NET Framework 2.0 ist das Element <connectionStrings>. Hier tragen Sie die Verbindungszeichenfolge für den Datenzugriff auf eine Datenquelle mittels ADO.NET ein. Sie können bei Bedarf mehrere Verbindungen beschreiben, auch mit unterschiedlichen Providern. Damit erhöht sich die Flexibilität der Anwendung und ermöglicht darüber hinaus auch, die Auswertung von Datenquellen zu berücksichtigen, deren Existenz zur Entwicklungszeit noch nicht bekannt ist.

Mit dem <add>-Element wird eine Verbindungszeichenfolge beschrieben. connectionString, name und providerName sind Attribute des Elements. name macht die Verbindungszeichenfolge namentlich identifizierbar, und das optionale providerName-Attribut beschreibt den ADO.NET-Anbieter, der für den Zugriff auf den zugrunde liegenden Datenspeicher verwendet werden soll. Die Angabe der Datenquelle in connectionString erfolgt mit denselben providerspezifischen Angaben, die Sie auch dem Connection-Objekt von ADO.NET übergeben würden.

Der Zugriff auf die in einer Konfigurationsdatei definierten Verbindungszeichenfolgen ist sehr einfach. Etwas übertrieben mutet es im ersten Moment an, dass dafür mit ConnectionStringSettingsCollection eine andere Collection bereitgestellt wird, als es <appSettings> tut. Ein Element aus ConnectionStringSettingsCollection rufen Sie über die statische Eigenschaft ConnectionStrings der Klasse ConfigurationManager unter Übergabe des Bezeichners ab.

Jede Verbindungszeichenfolge in einer Anwendungskonfigurationsdatei wird durch die Klasse ConnectionStringSettings beschrieben, über deren Eigenschaften die Auswertung des Elements erfolgt. So kann beispielsweise über die Eigenschaft ConnectionString das gleichnamige Attribut ausgewertet werden, das maßgeblich für den Aufbau der Verbindung ist.

Da Sie für jedes Verbindungselement einen anderen Datenprovider angeben können, interessiert der Inhalt des Attributs providerName.

27.1.9 Beispielprogramm mit einer Anwendungskonfigurationsdatei 

Ich bin Ihnen noch ein Beispiel schuldig geblieben. Vielleicht erinnern Sie sich, dass ich in Kapitel 14 beschrieben habe, wie Sie eine Assemblierung mit einem starken Namen erstellen und in den Global Assembly Cache (GAC) eintragen können. Ich hatte auch angedeutet, dass innerhalb einer Konfigurationsdatei einer kompilierten Anwendung von einer alten Komponente auf eine neuere Version »umgeschaltet« werden kann. Nun ist der Augenblick gekommen, Ihnen zu zeigen, wie Sie das realisieren können. Auf geht’s!

Beschreibung des Szenarios

Wir stellen uns das folgende Szenario vor: Es wird eine Windows-Anwendung entwickelt. Die Anwendung ist auf Operationen angewiesen, die auch von anderen Anwendungen sinnvoll genutzt werden könnten. Deshalb ist es nahe liegend, für diese Operationen eine eigene Klassenbibliothek anzulegen und diese gleichzeitig mit einem starken Namen zu versehen. Die Version der Assembly sei 1.0.0.0. Die Assemblierung wird mit einer Installationsroutine verteilt und die Assembly bei der Installation im GAC (Global Assembly Cache) des Endanwenders registriert.

Im nächsten Schritt wird die Assembly so überarbeitet, dass die öffentliche Schnittstelle zwar abwärtskompatibel bleibt, sich aber die Codeimplementierung ändert. Die neue Version wird anschließend ebenfalls verteilt und in den GAC eingetragen. In diesem Moment liegen zwei Versionen derselben Komponente vor. Die Windows-Anwendung, in deren Manifest die alte Version der Assembly eingetragen ist, wird zur Laufzeit weiterhin auf die erste, nun aber veraltete Version zugreifen, denn mit dieser Vorgabe wurde die Anwendung kompiliert.

Vielleicht ist mit der neuen Version der Assembly aber ein Fehler im Programmcode der alten Version beseitigt worden. Dann wäre es sinnvoll, wenn die Windows-Anwendung die verbesserte Komponente nutzen könnte. Mit einer Anwendungskonfigurationsdatei ist das möglich, da deren Einträge die Entsprechungen im Manifest einer Anwendung überschreiben. Auf diese Weise zwingen wir die Anwendung, die überarbeitete Assembly aufzurufen – und das ohne Neukompilierung.

Eine Anwendung mit einer globalen Assembly

Im ersten Schritt schaffen wir uns zunächst die Grundlage und stellen die globale Assembly bereit. Dazu ist ein Projekt vom Typ Klassenbibliothek erforderlich.

Weil sich die Assemblierung in den GAC eintragen soll, muss sie einen starken Namen haben. Dazu ist es notwendig, dem Projekt eine Schlüsseldatei hinzuzufügen. Diese können Sie mit dem SN-Tool erzeugen, z.  B.:

Die Schlüsseldatei sollte sich im Projektverzeichnis befinden und muss dem Projekt darüber hinaus auch ausdrücklich hinzugefügt werden (im Kontextmenü des Projekts über Hinzufügen Vorhandenes Element hinzufügen).

Eine Alternative zum SN-Tool liefert das Eigenschaftsfenster des Projekts. Wählen Sie hier die Lasche Signierung, und generieren Sie eine neue Schlüsseldatei. Optional können Sie hier auch eine bereits existierende einbinden. In der Datei AssemblyInfo.vb wird abschließend noch die Versionsnummer der Komponente unter AssemblyVersion eingetragen.

Jetzt kann das Projekt kompiliert werden. Als Ergebnis liegt abschließend eine DLL vor, die einen starken Namen hat und deshalb in den Global Assembly Cache eingetragen werden kann. Hierzu bietet sich ein Setup-Projekt an, mit dem Sie eine obligatorische Setup-Routine erstellen können.

Wenden wir uns nun zunächst der Windows-Anwendung zu, die auf die globale Komponente ProcessServer zugreift. Die Anwendung soll WinTestApp heißen und sofort nach dem Start die eingebundene Komponente aufrufen, die natürlich unter Verweise eingetragen sein muss.

Die neue Version einer globalen Assembly

Es kommt nicht selten vor, dass eine einmal verteilte Komponente überarbeitet werden muss. Die Gründe hierfür können unterschiedlich sein:

Es stellt sich heraus, dass die Komponente einen Bug enthält.

Der Programmcode wird optimiert, um beispielsweise ein besseres Laufzeitverhalten zu erreichen.

Die Komponente soll durch weitere Funktionalitäten ergänzt werden.

Unabhängig davon, welcher Grund der auslösende Faktor ist, muss sichergestellt sein, dass auf einem Rechner, auf dem die alte Version der Komponente registriert ist, diese nicht blindlings durch die neue überschrieben wird.

Nehmen wir an, der Autor der Komponente ProcessServer möchte seine Komponente neu kompilieren, weil sich die Implementierung der Methode DoSomething verändert hat, z.  B.:

Die Datei AssemblyInfo.vb wird folgendermaßen geändert:

Mit dem Attribut AssemblyVersion wird die neue Versionsnummer in das Manifest geschrieben. Da die überarbeitete Version abwärtskompatibel ist, wird nur die Build-Nummer erhöht. Anschließend kann die neue Version kompiliert werden.

Unabdingbare Voraussetzung dafür, dass nachher auch alles einwandfrei funktioniert, ist, dass die gleiche Schlüsseldatei verwendet wird wie für die nun alte Version der Assembly. Schlüsseldateien, die einen öffentlichen und einen privaten Schlüssel beschreiben, sind in ihrer Kombination global eindeutig. Damit authentifiziert sich der Entwickler als der Autor der Komponente. Würde ein anderer Entwickler – in guter oder böser Absicht – eine gleichnamige globale Komponente entwickeln und verteilen, würde sich diese (mindestens) im öffentlichen Schlüssel von der Originalkomponente unterscheiden. Die Anwendung greift jedoch aufgrund der Informationen im Manifest weiterhin auf das Original zu.

Auch die neue Version wird mit einer Setup-Routine verteilt.

Betrachten wir die Situation eines Anwenders, der sowohl die globale Komponente ProcessServer, Version 1.0.0.0, auf seinem Rechner registriert als auch die überarbeitete Fassung im globalen Assembly Cache eingetragen hat. Die Anwendung WinTestApp zeigt sich völlig unbeeindruckt von der Tatsache, dass nun zwei gleichnamige Komponenten im GAC installiert sind – sie verrichtet klaglos ihren Dienst und zeigt an der Konsole immer noch

an. Nichts anderes steht im Manifest, und eine abweichende Information gibt es (noch) nicht.

Konfiguration einer Anwendung

Standardmäßig wird immer auf die Komponente zugegriffen, die im Manifest angegeben ist, also schon zur Kompilierzeit bekannt war. Es stellt sich nun die Frage, wie einer Anwendung mitgeteilt werden kann, die neue Version aufzurufen und die alte zu ignorieren. Mit anderen Worten: Die Ausgabe der Anwendung WinTestApp soll

lauten – und das ohne Neukompilierung. Die Lösung lautet ganz einfach: In der Konfigurationsdatei muss eine entsprechende Umleitung erfolgen.

Wir wollen uns nun die Konfigurationsdatei ansehen, die es der Anwendung WinTestApp ermöglicht, auf die Version 1.0.1.0 der ProcessServer-Komponente zuzugreifen.

Unter der Sektion <configuration> wird mit <runtime> ein neuer Abschnitt definiert. Zwischen <assemblyBinding> und </assemblyBinding> sind die Informationen aufgelistet, die für die Umleitung der Aufrufe an globale Assemblies verantwortlich sind. Jede Umleitung wird innerhalb eines eigenen <dependentAssembly>-Elements beschrieben.

Innerhalb des <dependentAssembly>-Abschnitts wird mit dem Subelement <assemblyIdentity> die Identität der globalen Assembly festgelegt, an die der Aufruf des Codes gerichtet werden soll. Die erforderlichen Informationen werden als Attribute festgelegt. Dazu gehören:

der einfache Bezeichner der Assemblierung

die Kulturinformationen

der Token des öffentlichen Schlüssels

In unserer Beispielkonfigurationsdatei lautet der Eintrag dementsprechend wie folgt:

name, publicKeyToken und culture sind Attribute des Elements assemblyIdentity und spezifizieren exakt die globale Assembly. Die Angaben werden von der Common Language Runtime dazu benutzt, im GAC nach der Assembly zu suchen. Da im GAC aber nicht nur zwei, sondern auch x-beliebig viele Versionen der Assembly eingetragen sein könnten, muss man der CLR nur noch mitteilen, welche Version ersetzt werden soll, und insbesondere natürlich auch, durch welche. Dazu dient das Element <bindungRedirect>. Sehen wir uns die entscheidende Zeile in unserer Anwendungskonfigurationsdatei an:

Das Attribut oldVersion gibt die alte Version an, newVersion die neue. Damit erfüllt die Konfigurationsdatei ihre Aufgabe. Die Common Language Runtime findet die Angabe über die eingebundene globale Komponente und nutzt sie, während der Eintrag im Manifest der Anwendung zur Bedeutungslosigkeit degradiert wird.

Die Attribute »oldVersion« und »newVersion«

Wie reagiert die Laufzeit, wenn unter oldVersion und/oder newVersion Angaben enthalten sind, die nicht den Einträgen im GAC entsprechen?

Die Angabe der alten, zu ersetzenden Komponentenversion spielt zunächst keine Rolle. Existiert die Version nicht, wird die Aufrufumleitung ignoriert und die notwendige Bindungsinformation aus dem Manifest bezogen. Etwas sensibler ist die Reaktion, wenn oldVersion einen gültigen Eintrag im Global Assembly Cache beschreibt und unter newVersion eine Versionsnummer angegeben ist, die im GAC nicht vertreten ist – es kommt zu einem Laufzeitfehler vom Typ FileLoadException.

Häufig kommt es vor, dass mehrere ältere Versionen durch eine neue ersetzt werden können. Um einer Anwendungskonfigurationsdatei mehr Allgemeingültigkeit mit auf den Weg zu geben, kann man hinter oldVersion einen Versionsbereich festlegen, z.  B.:

Die Beispiele auf der CD

Auf der Buch-CD finden Sie alle in diesem Abschnitt erwähnten Projektdateien. Um die Auswirkung der Anwendungskonfigurationsdatei zu testen, müssen Sie zuerst die Setup-Routine des Projekts SetupProcessServerVersion1.0.0.0 ausführen. Hierbei handelt es sich um die Datei setup.exe, die im Unterordner Debug zu finden ist.

Bevor Sie das Testprojekt WinTestApp starten, sollten Sie in der Entwicklungsumgebung prüfen, ob der Verweis auf die Komponente ProcessServer richtig gesetzt ist. Kompilieren Sie anschließend die Windows-Anwendung, und führen Sie sie aus. Es sollte das Meldungsfenster der Assembly angezeigt werden mit Angabe der Version 1.0.0.0.

Installieren Sie nun die überarbeitete Version von ProcessServer (ProcessServerVer-sion1.0.1.0). Der erneute Start der EXE-Datei von WinTestApp beweist, dass die Anwendung weiterhin die ursprüngliche Fassung der globalen Assemblierung abruft.

Im gleichen Verzeichnis wie WinTestApp.exe habe ich auch die Vorlage für die Anwendungskonfigurationsdatei unter WinTestApp.exe.txt abgelegt. Sie müssen die Datei nur vorschriftsmäßig in WinTestApp.exe.config umbenennen. Dann sollte das erneute Ausführen von WinTestApp.exe dazu führen, dass die Laufzeit sich die neue Assembly aus dem GAC für den Aufruf der Operation besorgt.

27.1.10 Die Herausgeberrichtliniendatei 

Eine Herausgeberrichtliniendatei ist eine Konfigurationsdatei, die vom Komponentenentwickler zu einer Assembly kompiliert und im GAC installiert wird. Das Kompilat, die so genannte Herausgeberrichtlinien-Assembly, wird mit einer überarbeiteten globalen Assembly ausgeliefert. Herausgeberrichtliniendateien bieten sich insbesondere dann an, wenn sich in der älteren Version einer globalen Assembly ein Fehler herausgestellt hat und der Entwickler der globalen Assembly sicherstellen möchte, dass sich alle Anwendungen an die neue Version binden.

Der Inhalt der Herausgeberrichtliniendatei entspricht strukturell dem einer Anwendungskonfigurationsdatei. Der Name der Datei darf jedoch beliebig festgelegt werden. Für das Erzeugen der Herausgeberrichtlinien-Assembly müssen Sie allerdings auf ein Kommandozeilentool zurückgreifen, weil es einen entsprechenden Assistenten im Visual Studio 2005 nicht gibt. Bei dem Tool handelt es sich um den Assembly Linker al.exe, der im Verzeichnis

\Windows\Microsoft. NET\Framework\v<Frameworkversionsnummer>

zu finden ist.

An der Eingabeaufforderung muss ein verhältnismäßig komplexer Befehl abgesetzt werden, in dem zuerst der Name der Publisher-Richtliniendatei, also der XML-Datei, angegeben wird, daran anschließend der Name der resultierenden Herausgeberrichtlinien-Assembly und zum Schluss auch noch die Schlüsseldatei.

al /link:<Publisherrichtliniendatei> /out:<Ausgabedatei> /keyfile:<SNK-Datei>

Dem Bezeichner der Ausgabedatei, also der Herausgeberrichtlinien-Assembly, ist besondere Aufmerksamkeit zu widmen, da sie ein besonderes Format aufweisen muss. Er könnte beispielsweise lauten:

Dem Bezeichner ist das Wort policy voranzustellen, dem sich jeweils durch einen Punkt getrennt aus der Versionsnummer der Assembly die Haupt- und Nebennummer anschließt. Danach wird noch die DLL-Datei der Assemblierung genannt.

Damit könnte der Befehl zur Generierung einer Publisher-Richtlinien-Assembly wie folgt lauten:

Eine Bindung an eine neue Assembly-Version im GAC umzuleiten, ist ein gravierender Eingriff auf dem Rechner eines Benutzers. Durch die Angabe der Schlüsseldatei, die natürlich dieselbe sein muss, mit der auch der starke Name der Assembly erzeugt wird, sichert der Entwickler seine Berechtigung für diesen Eingriff zu.

Die Herausgeberrichtlinien-Assembly muss zusammen mit der Assembly im GAC installiert werden. Dazu können Sie wieder das Tool gacutil mit dem Schalter /i benutzen, z.  B.:

Einfacher ist es auch hier, die Herausgeberrichtlinien-Assembly zusammen mit der überarbeiteten globalen Assembly in eine Installationsroutine des Windows Installers zu verpacken, um den Prozess benutzerfreundlich zu automatisieren.